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METHOD FOR RESOLVING ARBITRARILY identify a symbol thai will eventually point to the correct 

COMPLEX EXPRESSIONS AT LINK-TIME address for updated data, define bow to change the data to 

be relocated, and identify the offset vafue (the amount to add 

FIELD OF THE INVENTION or subtract from the data to be relocated) if needed. Relo- 

S cation entries arc capable of being "extended" so that the 

This invention relates to the resolution of arbitrarily- files in which the relocation entries reside can be customized 

complex expressions as a computer program is linked to function with a particular piece of hardware (e.g., a 

together, rather than at run-time. Specifically, the present Pentium processor). 

invention enables relocation values in relocatable object files It is desirable to run digital signal processors (DSP's) and 

to be specified as arbitrarily-complex expressions. 1Q other microprocessors typically used in embedded applica- 
tions as fast as possible; thus, it is preferable to reduce the 

BACKGROUND OF THE INVENTION number of operations that are required during the execution 

Urge software systems are commonly divided into com- sta S c < mc ^^J^ 0 * T ° *? icvc 1 ^ ^ ""J 

ponents called modules. These modules, usually organized options as possible should be performed during build 

into files called object files (one module per file), must be 15 Umc - 15 com P l1 ^. ^e and/or link-tune, as 

tied to one another to form executable files before they °PP° se 1 d [ i0 me ™ tune > smce famm S » not 35 ^tart during 

operate. Before a program can be loaded into an end-user's ^ bufldui S of me application as it is during run time, 

computer for use it must be compiled, that is, converted from Arbitrarily-complex expressions are algebraic expres- 

source code format in which the programmer typically sions that have no anmcial limits on nesting depth or the use 

writes the program to object code format which will be 20 of particular operators or data items. In software systems, 

recognized by the end-user's computer. It must also be arbitrarily-complex expressions involving relocatable labels 

linked, which includes computing proper addresses of all can onl y bc resolved at link-time or at run-time because the 

modules which comprise the compiled program. The output final values of those labck are not untn the ^j*** 

of compiling is usually one or more relocatable object files files m UQked together. Generally, expressions in source or 

which are combined during linking into a single executable 25 object files that involve symbolic labels and that are resolved 

program. Linking cannot be completed until all modules al ^ m t0 sun P le expressions (e.g., a label 

(object files) are fully defined. P lus m immediate value), if such expressions are able to be 

. . . - , . . , , resolved at all. Linking is the last step in the creation 

Like most programs, an object file comprises lines of code .... * - , r . „ 

■ . t . . , l ' . c a ^ (building) of an executable program and is normally per- 

which mstruct the computer to carry out specific functions. \ ju.iiijvi ijo- . J- * 

« ~ • . f .... V , • , C1 ... . in formed by a tool called a linker or loader Since most object 

Quite often an instruction within the object file will make c , f . t r ... 

- 4 .. ... ,l tL file formats are not capable of representing arbitranly- 

reference to another instruction within the same or another , . , . j i 

T . c, . ■ . t - V7: „ !. complex expressions as relocaUon values, current develop- 

object file. For example, an instruction might tell the com- \ t . r , n . • \. t ., , r 

* . • i jj . L r 4 , mcnt tool sets usually require that arbitrarily-complex 

puter to go to a pamcu ar address in the object file (e.g., lme essions be indepei 4 nt i; specified to , he link ; r ^ugh 

4) and perform a function. S . t . £1 r . r , u J 7 u c j . r i 

' r 35 a linker control file, if they are to be performed at link-time. 

Aproblem arises when two or more object files are linked. A ^ contro] ffle ^ m addilional file that ; Ddep endently 

Since each object file is created I independently of the other the linker how to CQm (he arbilrarily<omplcx 

object files, the addresses used in one file will bear no cxprcssioDS . Relocation entries in the object file produced by 

relationship to those of another. For example, if an object file me assembler instruct the linker how l0 ^ lhe resuhs of me 

has a starting address of 50, the code addresses for that file <o computation . Uaing linkcr filcs rcquircs addit ional 

will progress upward I in sequence (e.g 51, 52, 53, etc ). ^ iatervention t0 specify the arbitrarily-complex expres- 

When several object files are linked to form an executable sion whcn lmki ^rcas objcct mcs arc deh'berately 

file, each line of code in the object files that make up the wriUen M ^ ± can ^ U£ed tedl for different 

executable file are assigned new addresses within die functions, me linker control file is an extra file that has to bc 

executable file. Thus, when a hne ofcode from the object file 45 Wfi debugged ^ edited ea ch time a group of object 

tells the computer to go to line 52 and perform an operation, flles are lmked M6iiioQ ^ symbols m required to support 

hne 52 of the executable file may not be the desired line. ^ ^ ffle expressionSi Furmerj me hnktT 

To solve this problem, relocatable object files are used. A fii es cannot be used within object files that are stored as 

relocatable object file is assigned addresses relative to modules within library archives, and the linker control files 

memory location zero. Thus, since the first memory location 50 cannot be used in dynamically linked libraries (DLL's), 

is a known constant, the location of each line of code in a smce both contain only module data and the values in the 

particular object file can be calculated and the instruction linker control file will change with each application. Use of 

that directs the computer to a particular line can be adjusted ^ CT control files also makes programs more error-prone, 

accordingly to reflect the location of the line within the since they require the programmer to write the linker control 

executable file in which the object file is used. This allows 55 fii c ; D ordcr to CTcatc "dummy" symbols. The programmer 

a programmer to code sections of programs without being also has to modify the source program to make reference to 

concerned about the final arrangement of the code when it is me dummy symbols. The linker has to obtain information 

linked to form the executable file. fr 0m both the linker control file and the relocaUon entry. 

An assembler is used to generate a relocatable object file, This places limitation on the ability of the linker to, deter- 

and the linker then combines the data from the object files, 60 mine if there are any conflicts between the obtained infor- 

If an instruction or data item within an object file makes mation and other information in the program (e.g., multiple 

reference to another instruction or data item with the same uses of the same symbols or definitions of a symbol in an 

or another object file, this reference may have to be updated. object file instead of in a linker control file). 

This is traditionally accomplished through the use of relo- if arbitrarily-complex expressions could be built into the 

cation entries. 65 object file during build time, then there would be better 

Each relocation entry consists of three or four fields. The performance during run-time. Conventional relocation 

fields identify what data is going to have to be updated, entries are incapable of representing such expressions, how- 
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ever. Thus, if such expressions can be specified at all, they 
must be explicitly specified to the linker through some other 
means, such as the above-mentioned linker control file 
method. 

Specifying arbitrarily-complex expressions directly in the 
object files would make building programs easier and less 
error-prone, and would allow libraries of object files to be 
self-contained and include any expressions that they use in 
the object file itself. It would also allow expressions to be 
used in conjunction with deferred (e.g., dynamic) linking, 
such as using a dynamically linked library (DLL) whose 
final address is not known until just before it is used. 

Previous attempts to encode expressions into traditional 
object files have revolved around using strings of characters 
to represent expressions. This requires reserving a place in 
the object file to store the strings,and the linker must parse 
and reinterpret the strings in order to resolve them. This is 
a time consuming operation which may introduce errors, 
since the linker is reinterpreting the expression, including 
symbol names which may not be unique. Conventional 
standard object file formats do not support such expression 
strings, which leads to non-standard variants. 

SUMMARY OF THE INVENTION 

The present invention takes advantage of the ability to 
extend-the relocation entries of object files by including 
rstack operations in the relocation entries. Specifically, by 
adding PUSH, POP, and EVALUATE operations to the 
relocation entries, postfix notation (also known as "reverse 
Polish notation") can be utilized to allow the resolution of 
arbitrarily-complex expressions during the linking operation 
and within the object file itself. 

In one embodiment, the standard PUSH operation can be 
used to push a symbol or label onto the stack. This is 
appropriate when the format of the program allows the use 
of an addend field. In formats that do not support the addend 
field, a PUSH IMMEDIATE operation can be used to push 
a value onto the stack. The stack operations are added to the 
relocation entries without modifying the object file format. 
This means that tool developers and end users can use 
standard object file formats (e.g., ELF or COFF) using 
standard tools or libraries for accessing them. 

BRIEF DESCRIPTION OF THE DRAWING 

FIG. 1 is a table showing a relocation entry of the prior 
art; 

FIG. 2 is a table showing relocation entries according to 
the present invention. 

FIGS. 3 and 3 A are a flowchart of the operation of the 
present invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

FIG. 1 shows an example of a prior art relocation entry 
format in a prior art relocatable object file. In this example, 
the ELF (Executable and Linking Format) format is utilized; 
thus, conventional ELF field names (e.g. r_offset) are 
shown. 

Referring to FIG. 1, line 1 shows a data pointer, known as 
a "data offset," at column 10. The ELF field name is 
"r_offset". This datum identifies the location at which to 
apply the relocation action (e.g., the example in FIG. 1 
points to a "GOTO instruction" reference). For a relocatable 
file, the value of the oflset is expressed in the object file as 
a byte offset or instruction offset to the storage unit affected 
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by the relocation e.g., if the GOTO instruction reference is 
the third instruction in the object file, it is coded as "3" as 
shown. 

Column 20 illustrates the ELF field "r_info". This field 
identifies both the relocation type to apply e.g., "GOTO 
relocation", and the symbol table index with respect to 
which the relocation must be made, e.g. LABEL1. 

Column 30 illustrates the ELF field "r_addend", which, 
10 under conventional operation specifies a constant addend 
used to compute the value to be stored in the relocate field. 
For example, in the above example, if the source program 
contained "GOTO LAB ELI +5", the addend's value would 
be 5. Since the example in FIG. 1 shows an addend of 0, the 
15 source program coded therein reads "GOTO LABEL1". 

The above explanation illustrates the conventional 
instructions that are found in the relocation entries of a 
conventional relocatable object file. Suppose, however, that 
the source program contains "GOTO (LAB ELI -LAB EL2)/ 
4". Under the prior art methods, a linker control file would 
have to be created to perform the arithmetic calculations 
(subtract and divide), with the result from the linker control 
file calculations being used in the object file. According to 
the present invention, instead of having to create and invoke 
a linker control file to perform the subtraction and division 
operations, stack commands are used directly in the reloca- 
tion type field of the relocation entry to enable the resolution 
of these arithmetic operations. A stack is a well-known way 
to store data such that the last object put on the stack is the 
first object retrieved (also called LIFO, for last -end-first- 
out). Stack operations are commonly used, for example, by 
Hewlett-Packard calculators to calculate arithmetic 
expressions, taking advantage of postfix (reverse Polish) 
notation. 

Referring to FIG. 2, according to the present invention, 
for the operation "GOTO (LABELl-LABEL2)/4", the stack 
command "PUSH LAB ELI" pushes the value correspond- 
ing to LABEL1 onto a stack maintained by the linker. Next, 
the stack command "PUSH LABEL2" pushes the value 
corresponding to LABEL2 onto the stack, on top of the 
LABEL1 value. "Binary EVALUATE" at line 3 causes the 
execution of the mathematical operation "SUBTRACT" on 
the top two items on the stack (i.e., LABEL1-LABEL2). 
45 This replaces the LABEL1 and LABEL2 items on the stack 
with the result of the subtraction. 

At line 4, the stack command "PUSH 4" pushes the 
divisor, in this case, a "4", onto the stack At line 5, "Binary 
EVALUATE" causes the execution of the mathematical 
operation "DIVIDE" on the top two items on the stack, and 
replaces the top two stack items with the result of the 
division. Finally, at line 6, "POP* removes the result and the 
"GOTO relocation" moves it to the proper location for 
5s updating the GOTO instruction. 

If the GOTO instruction is the third instruction in the 
object file; LAB ELI and LABEL2 are the second and third 
symbols, respectively, referenced in the symbol file (the file 
that contains the symbol definitions); PUSH, EVALUATE, 

60 POP and GOTO Relocation arc relocation types 1, 2, 3, and 
4, respectively, referenced in a "relocation type file" (a file 
that contains the relocation type definitions); the "Binary 
EVALUATE SUBTRACT" and "Binary EVALUATE 
DIVIDE" are the second and fourth operations, respectively, 

65 in the "Binary EVALUATE Operation" file (a file that 
contains the Binary EVALUATE Operation definitions), 
then these operations would be encoded as follows: 
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constraints. Although the only operand constraints recog- 
nized in the preferred embodiment are the number of input 
operands, additional constraints are possible. These could 
include, for example, whether to remove the operands from 
the stack, how to provide Lhe results, or which of several 
stacks to use. Operand constraints could also be applied to 
the PUSH and POP operations (this would be needed if 
multiple stacks were used). 
These operations can also be encoded without the use of 
Relocation is performed by the linker after it knows where 10 an addend field. This can reduce the amount of coding 
all of the instructions and data will reside in the executable required and also allows the use of the present invention 
file. When a conventional relocation type (e.g., "GOTO with otner formats that do not support an addend field, such 
instruction") is encountered, the value of the specified ^ C0FF (Common Object File Format). In such a case, if 
symbol e.g., LABEL1) is retrieved (0 is used if no symbol m EVALUATE relocation type is specified the symbol 
is given) and the addend (if used) is added to it. The data at 15 imef of |he field would avse ^ EVALUATE 

the specified address is updated in a way determined by the ^ ( SUBTRACT^ to be performed. Similarly, if 

relocation type, in a conventional manner. a pQp relocatioa t ^ me symbol poinler of lhe 

FIGS. 3 and 3A are a flowchart illustrating the operation ^ ficld would cmsc thc P0P operation (e.g., the 
of the present invention as described in more detail below. previously meQ tioned "GOTO relocation" operation) to be 
When a PUSH (a non-conventional relocation type) is ^ formcd ^ additio nal PUSH IMMEDIATE relocation 
encountered, the value of the symbol (plus the addend, if would be ^ {Q gpecify vahies father ^ 

used) is pushed onto a stack which is initially empty If no bo]s m thc symbol ficld (which can bc to build 

symbol is specified, then the value in the addend field largef yalues mat WQuld Qot fit - m the symbol pomter) , n 
represents an "immediate value' , i.e., a number that will be othcf WOfd ^ ^ EVALUATE, POP, and PUSH IMMEDI- 
added, subtracted, or otherwise used in computation. When ^ ^ re i OC ation types use the symbol field in the same way 
an EVALUATE relocation type is encountered, the addend that ^ EV ALUATE, PUSH, and POP relocation entries use 
field is used in a different manner than it is used under the ^ add(md fieM m the iousl describe ELF format 
prior art. When the EVALUATE relocation type is encoun- example 

tered the value in the addend field identifies what type of r , ' , , , . . , ,. a . 

EVALUATE .o execute, Le., (he addend is simply an iden- 30 f It l f h °" ld !* W rec ^' ed « h » t vani T nS ^"^'T 
tifying code. For example, in FIG. 2, a "2" in the addend of tne h ' re,D desenbed system and methods, within he 
field Indicates a "SUBTRACT" function and a "4" indicates SC0 P e of «"» '^eouon wiU be apparent to those stalled in the 
a "DIVISION" function, each as defined in the Binary art Accordingly the foregouig descripUon should be taken 
EVALUATE Operation table discussed above. The selected " lUus^aUve and not m a lim.ting sense, 
function is performed on the top items on the stack (the top 35 , C A C aim J , , , . . 
item for a UNARY EVALUATE, the top two items for a . ^ method of resolving an amitranly^mplex expres- 
BINARY EVALUATE, and the top three items for a TRI- SJon bcf ° rc * « m ^ rt ' d mt0 ^ executable object file, said 
NARY EVALUATE). Once the EVALUATE function is ^ecutable object file having at least one instruction and/or 
performed, the items on the stack subjected to the EVALU- data Uem Te * m ™Z ^elocaUon, comprising the steps of: 
ATE function are replaced with the single result. When a 40 g cncratin g a relocatable object file having at least two 
POP is encountered, the addend field actually contains a relocation entries; 

conventional relocation type. The value on the top of the inserting one or more stack operations into each said 
suck is removed from the stack and used to update the data relocation entry; 

at the address specified in a conventional manner. processing said relocatable object file with a linker; and 

Although only UNARY, BINARY and TRI NARY evahi- 45 outputting the result of said processing by said linker to 
ate operations are disclosed in detail, the EVALUATE said executable object file, wherein two or more of said 

operation need not be limited to one of these three. EVALU- relocation entries may be applied to a single instruction 

ATE can support zero operands (e.g., to insert an irrational and/or data item. 

constant such as pi or e, or to access linker-provided 2. A method as set forth in claim 1, wherein said stack 
information). It also supports a greater number of operands 50 operations are inserted in relocation entries of said relocat- 
(e.g., to evaluate functions with four or more input able object file. 

arguments). Further, EVALUATE can directly access the 3. A method as set forth in claim 1, wherein said stack 
stack for the purposes of getting operands or storing results operations comprise PUSH, POP, and EVALUATE opera- 
without necessarily removing all operands from the stack tions. 

and replacing them with the result (as is done in the 55 4. A method as set forth in claim 1, wherein said stack 
preferred embodiment). operations comprise PUSH, PUSH IMMEDIATE, POP, and 

In the preferred embodiment, multiple relocation types EVALUATE operations, 
are assigned to correspond to EVALUATE. At least one 5. A method as set forth in claim 3, wherein said EVALU - 
relocation type is assigned to each set of operand constraints ATE operations comprise UNARY, BINARY, and TRI- 
that may be placed upon the EVALUATE operations (e.g., 60 NARY EVALUATE operations. 

number of input operands, which may be UNARY, 6. A method asset forth in claim 4, wherein said EVALU- 
BINARY, or TRI NARY). An alternative embodiment uses ATE operations comprise UNARY, BINARY, and TRI- 
only one relocation type and encodes the operand constraints NARY EVALUATE operations. 

into the field that specifies the operation to be performed (the 7. A method of resolving an arbitrarily-complex exprcs- 
addend field in the preferred embodiment). Another alter- 65 sion before it is inserted into an executable object file, said 
native embodiment uses a separate field (such as the symbol executable object file having at least one instruction and/or 
pointer, contained in "r-info ") to specify the operand data file requiring relocation, comprising the steps of: 
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generating a relocatable object file having at least two relocation entries may be applied to a single instruction 

relocation entries; and/or data item. 

extending said relocation entries to include one or more 14. A method as set forth in claim 13, wherein said stack 

stack operations; operations are inserted in relocation entries of said relocal- 

resolving said arbitrarily-complex expression using said 5 *b\t object file. 

stack operations; 15. A method as set forth in claim 13, wherein said stack 

inserting the results of said resolved expression into said operations comprise PUSH, POP, and EVALUATE opera- 
relocatable object file; ^ons. 

* j i ... 4 fil „ ,. . 16. A method as set forth in claim 13, wherein said stack 

process ice said relocatable object file with a linker and 10 . . „ _ ' ^ 

y . * , r ^ -j.-, operations comprise PUSH, PUSH IMMEDIATE, POP, and 

outputtmg the result of said processing by said linker to EVALUATE operations. 

said executable object file, wherein two or more of said . t , r , t f . . . - c . ., 

, • « i* j * * i • » *• 17. A method as set forth in claim 15, wherein said 

relocation entries may be applied to a smgle instruction A _ TTXT ___ ' 

and/or data item EVALUATE operations comprise UNARY, BINARY, and 

8. A method as set forth in claim 7, wherein said stack 35 ™NARY EVALUATE operations. 

operations are inserted in relocation entries of said relocat- IS A method 45 forth m cUim 16 > wherein said 

able object file. EVALUATE operations comprise UNARY, BINARY, and 

9. A method as set forth in claim 7, wherein said stack TRINARY EVALUATE operations. 

operations comprise PUSH, POP, and EVALUATE opera- 19. A computer-implemented system for resolving 

tions. 20 arbitrarily-complex expressions in a relocatable object file at 

10. A method as set forth in claim 7, wherein said stack link-time, said system configured to perform the following 
operations comprise PUSH, PUSH IMMEDIATE, POP, and steps: 

EVALUATE operations. extend the relocation entries of said relocatable object file 

11. A method as set forth in claim 9, wherein said to incIude operations; 

EVALUATE operations comprise UNARY, BINARY, and 25 . . , . , . . 

TRINARY EVALUATE operations. resolve arbitrarily-complex expressions using said 

12. A method as set forth in claim 10, wherein said slack °P eratIons ; ™ d 

EVALUATE operations comprise UNARY, BINARY, and insert the results of said resolved expressions into said 

TRINARY EVALUATE operations. relocatable object file. 

13. In a software system, a method of resolving an 30 20. A system as set forth in claim 19, wherein said stack 
arbitrarily-complex operation before it is inserted into an operations are inserted in relocation entries of said relocat- 
executable object file, said executable object file having at able object file. 

least one instruction and/or item file requiring relocation, 21. A system as set forth in claim 19, wherein said stack 
comprising the steps of: operations comprise PUSH, POP, and EVALUATE opera- 
generating a relocatable object file having at least one 35 tions. 

relocation entry; 22. A system as set forth in claim 19, wherein said stack 

extending said relocation entries to include one or more operations comprise PUSH, PUSH IMMEDIATE, POP, and 

slack operations; EVALUATE operations, 

reading said extended relocation entries; . n 23 ■ A system as set forth in claim 21, wherein said 

n «»,™h.» rt fih-r»i« M #; rt n ..cJnncaM EVALUATE operations comprise UNARY, BINARY, and 

^TeraZir relocation entries using said TRINARY EVALUATE operations. 

P . , ' . , _ 24. A system as set forth in claim 22, wherein said 

inserting said new value into said relocatable object file; EVALUATE operations comprise UNARY, BINARY, and 

processing said relocatable object file with a linker; and TRINARY EVALUATE operations, 

outputting the result of said processing by said linker to 45 

said executable object file, wherein two or more of said * * * * * 
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